[Feature] Configurable Tempo & Owner-Triggered Epochs by evgeny-s · Pull Request #2638 · opentensor/subtensor

evgeny-s · 2026-05-06T11:36:12Z

Description

Implementation of the specification.

Demo (non-technical): https://dynamic-tempo-non-technical.netlify.app/
Demo (technical): https://dynamic-tempo-technical.netlify.app/#1

Related Issue(s)

Closes #[issue number]

Type of Change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation update
Other (please describe):

Breaking Change

Check the 11. Breaking changes & compatibility section.

Checklist

I have performed a self-review of my own code
I have commented my code, particularly in hard-to-understand areas
I have run ./scripts/fix_rust.sh to ensure my code is formatted and linted correctly
I have made corresponding changes to the documentation
My changes generate no new warnings
I have added tests that prove my fix is effective or that my feature works
New and existing unit tests pass locally with my changes
Any dependent changes have been merged and published in downstream modules

Screenshots (if applicable)

Please include any relevant screenshots or GIFs that demonstrate the changes made.

Additional Notes

Please provide any additional information or context that may be helpful for reviewers.

Simulations (miner rewards Events):

Trigger epoch:

Set tempo:

gztensor · 2026-05-06T20:52:23Z

-        Self::blocks_until_next_epoch(netuid, Self::get_tempo(netuid), current_block) == 0
+        let tempo = Self::get_tempo(netuid);
+        if tempo == 0 {
+            return false;


This means that if tempo is set to 0, manual trigger or max cap of MAX_TEMPO will not work. Is this by design?

Yes, the previous implementation meant that if tempo is 0, we don't run tempo on this subnet.
We don't have this case in Mainnet, but we support it. There is still a possibility to set the tempo to 0 by the root.
So we support the same semantics.

gztensor · 2026-05-06T20:57:21Z

+    /// stateful scheduler (period `tempo + 1`, anchored on `LastEpochBlock`). Used by the
+    /// admin-freeze-window predicate and external tooling. Returns `u64::MAX` when
+    /// `tempo == 0` (legacy defensive short-circuit).
    pub fn blocks_until_next_epoch(netuid: NetUid, tempo: u16, block_number: u64) -> u64 {


"Period is tempo + 1: next firing at last + tempo + 1." comment and the code below is not anymore correct.

Updated the function name and the comment to avoid the confusion: ad7ba80

gztensor · 2026-05-06T20:58:17Z

+
+        let now = Self::get_current_block_as_u64();
+
+        Tempo::<T>::insert(netuid, tempo);


Should this be a function since Tempo and LastEpochBlock are always updated together?

Added a helper function: df184e3

evgeny-s · 2026-05-13T09:47:15Z

Hey, @basfroman , we have a bunch of tests that failed on the SDK side.
The main reason is now we have a stateful calculation for the next epoch block, because the tempo is dynamic.
So, here you can just call the new runtime API - get_next_epoch_start_block.

open-junius · 2026-05-13T13:08:10Z


+    /// Effective activity cutoff in blocks, derived from `ActivityCutoffFactorMilli` and `Tempo`.
+    /// `cutoff_blocks = (factor × tempo) / 1000`, clamped to ≥ 1.
+    pub fn get_activity_cutoff_blocks(netuid: NetUid) -> u64 {


should we use it to replace get_activity_cutoff everywhere? for instance in metagraph.

Yes, because ActivityCutoff is deprecated and will be removed in the follow-up release.
Who can help with updating it?

It is fine to remove the storage later. Actually, my question is for https://github.com/opentensor/subtensor/blob/devnet-ready/pallets/subtensor/src/rpc_info/metagraph.rs#L713, if we should use get_activity_cutoff_blocks to replace get_activity_cutoff? It will change the return type, from u16 to u64.

Good catch, for me to update:

metagraph call

breaking changes section in the description, regarding the metagraph

Could you please mark ActivityCutoff as #[deprecated(note = "Some explanation")]? It will propagate to metadata.

Added: be695df

@l0r1s , BTW, it generates a lot of warnings with the deprecation notice in tests. But I planned to remove it in the follow-up PR. Are we ok to keep warnings?

Updated Metagraph + for now commented the deprecation note, otherwise clippy is failing. We will remove it fully in the follow up PR: a8fee82

# Conflicts: # pallets/subtensor/src/utils/rate_limiting.rs

# Conflicts: # pallets/subtensor/src/coinbase/run_coinbase.rs # pallets/subtensor/src/macros/dispatches.rs # pallets/subtensor/src/macros/events.rs # pallets/subtensor/src/macros/hooks.rs # pallets/subtensor/src/tests/migration.rs # pallets/subtensor/src/tests/mod.rs # pallets/subtensor/src/utils/rate_limiting.rs

- Updated reveal/commit logic based on stateful epoch index - Updated migration for CR-v2 storage item

github-actions · 2026-05-25T10:32:40Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T11:03:18Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This migration still materializes every WeightCommits entry into a Vec before processing it. WeightCommits is live per-subnet/per-hotkey commit storage, so a large state can allocate beyond Wasm memory or exceed upgrade execution limits before the migration reaches its reads/writes accounting. Process entries in a streaming/bounded way, or split this into a bounded multi-block migration with persisted progress.

github-actions · 2026-05-25T11:03:18Z

            SubtensorModule::get_subnet_account_id(netuid)
        }
+
+        fn get_next_epoch_start_block(netuid: NetUid) -> Option<u64> {


[HIGH] Runtime changes need a spec_version bump

This PR changes runtime storage, dispatchables, pallet config, a runtime migration, and a runtime API, but RuntimeVersion still has spec_version: 407. Without bumping spec_version, upgrade coordination can fail because nodes do not see this as a new runtime version. Pinned here because the unchanged version line is outside the diff; bump spec_version in VERSION for this runtime-affecting change.

github-actions · 2026-05-25T11:03:27Z

🔄 AI review updated — Skeptic: VULNERABLE

…to make it cohesive with the emission distribution

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T12:00:34Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every CR-v2 commit entry across all subnets/accounts before rewriting them. This is user-scaled chain state, so a large live map can make the runtime migration exhaust Wasm memory or exceed block limits during on_runtime_upgrade. Stream the iterator and rewrite entries one at a time instead of collecting the full map first; account reads/writes incrementally inside the loop.

github-actions · 2026-05-25T12:00:34Z

            SubtensorModule::get_subnet_account_id(netuid)
        }
+
+        fn get_next_epoch_start_block(netuid: NetUid) -> Option<u64> {


[HIGH] Runtime changes need a spec_version bump

This PR changes the runtime API surface and pallet runtime behavior, but runtime/src/lib.rs still reports spec_version: 407. Without a spec version bump, nodes can treat incompatible native/Wasm runtimes as equivalent and clients may miss the runtime upgrade. Bump spec_version for this runtime-affecting change.

github-actions · 2026-05-25T12:00:44Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T12:05:52Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This migration materializes every WeightCommits entry before rewriting them. Because it runs from on_runtime_upgrade, the entire live CR-v2 commit set is allocated in Wasm memory in one block; WeightCommits cardinality is not bounded by this migration, so a sufficiently large live state can exhaust Wasm memory or exceed the upgrade block budget and stall/brick the runtime upgrade. Rewrite this as a bounded/streaming migration or split it into cursor-based chunks, and only mark the migration complete after all chunks are processed.

We have a few WeightCommits on mainnet, so we should be good.

github-actions · 2026-05-25T12:06:00Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T12:42:30Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every CR-v2 commit entry before rewriting any of them. This runs inside on_runtime_upgrade; if live commit storage is large enough, the upgrade can exceed Wasm memory or block weight and fail the runtime upgrade. Rewrite entries in a streaming/chunked way instead of collecting the full storage map first.

github-actions · 2026-05-25T12:42:40Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T14:07:58Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every CR-v2 commit queue in Wasm memory before the rewrite loop starts. WeightCommits is live runtime storage with no global bound across accounts/subnets, so a sufficiently large committed set can make the runtime upgrade exceed Wasm memory or block limits and abort the upgrade. Rewrite entries while streaming the iterator, or split this into a bounded/stepped migration that limits work and memory per block.

github-actions · 2026-05-25T14:08:08Z

🔄 AI review updated — Skeptic: VULNERABLE

… precompiles.

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-25T14:37:57Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() loads every live CR-v2 commit row into one Vec during on_runtime_upgrade. This storage is keyed by subnet/account and can scale with live users, so a sufficiently large state can exhaust Wasm memory or trap before HasMigrationRun is written, blocking the runtime upgrade. Rewrite the storage incrementally with a bounded/paged migration state, or otherwise avoid collecting the full map before processing.

github-actions · 2026-05-25T14:38:05Z

🔄 AI review updated — Skeptic: VULNERABLE

# Conflicts: # pallets/subtensor/src/macros/hooks.rs # pallets/subtensor/src/tests/migration.rs # runtime/src/lib.rs

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-27T09:14:30Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

This runtime migration still loads every WeightCommits entry into a Vec before rewriting them. WeightCommits is live, user-influenced commit-reveal storage, so a sufficiently large state can make the upgrade allocate unbounded Wasm memory and abort the runtime upgrade. Iterate and rewrite entries incrementally instead of collecting the full map first, or otherwise bound/chunk the migration so the upgrade cannot OOM.

github-actions · 2026-05-27T09:14:41Z

🔄 AI review updated — Skeptic: VULNERABLE

…low up PR)

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-27T09:37:50Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() loads every CR-v2 commit entry into a single Wasm heap allocation before rewriting anything. This storage is user-populated across netuids/accounts, so a runtime upgrade can OOM/trap before HasMigrationRun is written, blocking the upgrade. Rewrite entries in a streaming or bounded way, for example by iterating keys and updating each entry immediately, or split the conversion into a cursor-based migration with bounded per-block work and accurate weight accounting.

github-actions · 2026-05-27T09:38:01Z

🔄 AI review updated — Skeptic: VULNERABLE

github-actions

AI review — see the sticky summary comment for the verdict and the inline comments below for specific findings.

github-actions · 2026-05-27T11:55:31Z

+    // `(hash, commit_epoch, commit_block, _)` layout. Field 1 was the absolute
+    // `commit_block`; it becomes `commit_epoch` (legacy modulo epoch). Field 2
+    // keeps the absolute `commit_block` (used by the epoch column-mask).
+    let crv2_entries: Vec<_> = WeightCommits::<T>::iter().collect();


[HIGH] Migration collects unbounded commit storage into Wasm memory

WeightCommits::<T>::iter().collect() materializes every CR-v2 commit entry across all subnets/accounts into Wasm memory during the runtime upgrade before rewriting them. This storage is live and user-populated, so the migration can exceed block/Wasm memory limits and brick the upgrade path. Process the map in a bounded streaming/drain/translate pattern, or otherwise prove an enforced upper bound that fits the runtime-upgrade budget.

github-actions · 2026-05-27T11:55:40Z

🔄 AI review updated — Skeptic: VULNERABLE

evgeny-s added 2 commits May 6, 2026 12:55

Dynamic tempo implementation

d30a76f

clippy + fmt

42b3e29

evgeny-s added the skip-cargo-audit This PR fails cargo audit but needs to be merged anyway label May 6, 2026

evgeny-s changed the title ~~Dynamic tempo implementation~~ [Feature] Configurable Tempo & Owner-Triggered Epochs May 6, 2026

clean up

c6567e2

gztensor requested changes May 6, 2026

View reviewed changes

evgeny-s added 17 commits May 7, 2026 11:29

Renamed function + updated comment

ad7ba80

wrap set tempo + cycle reset with a helper function

df184e3

tests

b2e4658

clippy

02f43ee

Merge branch 'devnet-ready' into feature/dynamic-tempo

40f2773

fixed test from devnet

c3fa417

Merge branch 'devnet-ready' into feature/dynamic-tempo

dca9f44

- disable dynamic tempo for subnets with CR enabled.

73d1ab4

- update migration - do not clamp tempos

1ba4a3d

fix migration test

215f13b

Added benchmarks for new extrinsics

577d62b

Merge branch 'devnet-ready' into feature/dynamic-tempo

ff61eb3

fix for e2e test

e15d749

- Increase timeout

7a1d7a3

- updated name + timeout

4c06820

increase MAX_EPOCHS_PER_BLOCK for fast-runtime

82ae882

Added runtime API to get the next epoch start block

bcfe012

open-junius reviewed May 13, 2026

View reviewed changes

evgeny-s added 3 commits May 15, 2026 14:07

Merge branch 'devnet-ready' into feature/dynamic-tempo

34bcc41

# Conflicts: # pallets/subtensor/src/utils/rate_limiting.rs

- fix test after dev merge

b5b4184

github-actions Bot mentioned this pull request May 21, 2026

Ai reviewer #2668

Merged

4 tasks

- Added stateful SubnetEpochIndex

1fc3e88

- Updated reveal/commit logic based on stateful epoch index - Updated migration for CR-v2 storage item

Added a possibility to update activity cutoff for root

b528257

github-actions Bot reviewed May 25, 2026

View reviewed changes

Move LastMechansimStepBlock insertion after the distribute_emission, …

9f33cd4

…to make it cohesive with the emission distribution

github-actions Bot reviewed May 25, 2026

View reviewed changes

evgeny-s added 2 commits May 25, 2026 14:01

updated error comments

231f2bf

version bump

bdf45ca

github-actions Bot reviewed May 25, 2026

View reviewed changes

Commented deprecation note + updated activity_cutoff_usage

a8fee82

github-actions Bot reviewed May 25, 2026

View reviewed changes

evgeny-s added 2 commits May 25, 2026 16:05

Fixed precompile test

26dfe91

fmt

8024b7a

github-actions Bot reviewed May 25, 2026

View reviewed changes

- Added get_activity_cutoff_factor and set_activity_cutoff_factor for…

3e34671

… precompiles.

github-actions Bot reviewed May 25, 2026

View reviewed changes

Merge branch 'devnet-ready' into feature/dynamic-tempo

8a39d86

# Conflicts: # pallets/subtensor/src/macros/hooks.rs # pallets/subtensor/src/tests/migration.rs # runtime/src/lib.rs

github-actions Bot reviewed May 27, 2026

View reviewed changes

- commented deprecation because of clippy (will be removed in the fol…

877b41e

…low up PR)

github-actions Bot reviewed May 27, 2026

View reviewed changes

- fix safe math warning

48d7f90

github-actions Bot reviewed May 27, 2026

View reviewed changes


		let now = Self::get_current_block_as_u64();

		Tempo::<T>::insert(netuid, tempo);

Conversation

evgeny-s commented May 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Related Issue(s)

Type of Change

Breaking Change

Checklist

Screenshots (if applicable)

Additional Notes

Simulations (miner rewards Events):

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeny-s commented May 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

evgeny-s May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 25, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot May 25, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot May 25, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 25, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot May 25, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot May 25, 2026

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 25, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions Bot May 25, 2026

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

github-actions Bot commented May 25, 2026

Uh oh!

github-actions Bot left a comment

Choose a reason for hiding this comment

evgeny-s commented May 6, 2026 •

edited

Loading

evgeny-s May 25, 2026 •

edited

Loading